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(57) The invention provides improved computernel- 
work firewalls which include one or more features for 
increased processing efficiency. A firewall in accord- 
ance with the invention can support multiple security 
policies, multiple users or both, by applying any one of 
several distinct sets of access rules. The firewall can 
also be configured to utilize "stateful" packet filtering 
which involves caching rule processing results for one 
or more packets, and then utilizing the cached results 
to bypass rule processing for subsequent similar pack- 
ets. To facilitate passage to a user, by a firewall, of a 
separate later transmission which is properly in re- 
sponse to an original transmission, a dependency mask 
can be set based on session data items such as source 
host address, destination host address, and type of 
service. The mask can be used to query a cache of ac- 
tive sessions being processed by the firewall., such that 
a rule can be selected based on the number of sessions 
that satisfy the query. Dynamic rules may be used in ad- 
dition to pre-loaded access rules in order to simplify rule 
processing. To unburden the firewall of application prox- 
ies, the firewall can be enabled to redirect a network ses- 
sion to a separate server for processing. 
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Description 

Field of the Invention 

5 [0001] This invention relates to the prevention of unauthorized access in computer networks and, more particularly, 
to firewall protection within computer networks. 

Background of the Invention 

io [0002] In computer networks, information is conventionally transmitted in the form of packets. Information present 
at one site may be accessed by or transmitted to another site at the command of the former or the latter. Thus, e.g., if 
information is proprietary, there is a need for safeguards against unauthorized access. To this end, techniques known 
as packet filtering, effected at a network processor component known as a firewall, have been developed and com- 
mercialized. At the firewall, packets are inspected and filtered, i.e., passed on or dropped depending on whether they 

is conform to a set of predefined access rules. Conventionally, these rule sets are represented in tabular form. 

[0003] Typically, a firewall administrator allows broad access which is consented to from one side of the firewall to 
the other, but blocks transmissions in the opposite direction which are not pan of an active network session. For ex- 
ample, "inside" company employees may have unrestricted access through the firewall to an "outside" network such 
as the Internet, but access from the Internet is blocked unless it has been specifically authorized. In addition to such 

20 a firewall at a corporate boundary to the Internet, firewalls can be interposed between network domains, and can also 
be used within a domain to protect sub-domains. In each case, different security policies may be involved. 
[0004] In certain complex network protocols, separate, additional network sessions are required from the outside 
back to the user. One such complex protocol is employed by a service known by the trade name "RealAudio." Without 
special measures, the request for the separate session will be blocked by the firewall. 

2S [0005] For such complex protocols, separate "proxy" processes have been developed to run concurrently on the 
firewall processor on behalf of the user. Proxy processes have also been developed for other special-purpose appli- 
cations, e.g., to perform services such as authentication, mail handling, and virus scanning. 

[0006] In the interest of maximizing the number of sessions which can run concurrently, since the capacity of a firewall 
processor to support concurrent processes is limited, it is desirable to minimize the need for proxy processes on the 
30 firewall. Such minimization is desirable further in the interest of over-all transmission rate : as passage of incoming data 
through separate processes tends to slow transmission down. 

Summary of the Invention 

35 [0007] The present invention provides techniques for implementing computer network firewalls so as to improve 
processing efficiency, improve security, increase access rule flexibility, and enhance the ability of a firewall to deal with 
complex protocols. In accordance with a first aspect of the invention, a computer network firewall is able to support (a) 
multiple security policies, (b) multiple users, or (c) multiple security policies as well as multiple users, by applying any 
one of several distinct sets of access rules for a given packet. The particular rule set that is applied for any packet can 

40 be determined based on information such as the incoming and outgoing network interfaces as well as the network 
source and destination addresses. 

[0008] In accordance with a second aspect of the invention, a computer network firewall can be configured to utilize 
•statef ul" packet filtering which improves performance by storing the results of rule processing applied to one or more 
packets Statetul packet filtering may be implemented by caching rule processing results for one or more packets, and 
45 then utilizing the cached results to bypass rule processing for subsequent similar packets. For example, the results of 
applying a rule set to a particular packet of a network session may be cached, such that when a subsequent packet 
from the same network session arrives in the firewall, the cached results from the previous packet are used for the 
subsequent packet. This avoids the need to apply Ihe rule set to each incoming packet. 

[0009] In accordance with a third aspect of the invention, a computer network firewall authorizes or prevents certain 
so network sessions using a dependency mask which can be set based on session data items such as source host 
address, destination host address, and type of service. The dependency mask can be used to query a cache of active 
sessions being processed by the firewall, to thereby identify the number of sessions that satisfy the query. The query 
may be associated with an access rule, such that the selection of that particular rule is dependent on the number of 
successful matches to the query. 
ss [0010] In accordance with a fourth aspect of the invention, a computer network firewall may make use of dynamic 
rules which are added to a set of access rules for processing packets. The dynamic rules allow a given rule set to be 
modified based on events happening in the network without requiring that the entire rule set be reloaded. Exemplary 
dynamic rules include a "one-time" rule which is only used for a single session, a time-limited rule which is used only 
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[0028] The security policies can be represented by sets of access rules which are represented in tabular form and 
which are loaded into the firewall by a firewall administrator. As illustrated in Fig. 3, such a table can provide for cate- 
gories including rule number, designations of source and destination hosts, a designation of a special service which 
can be cailed for in a packet, and a specification of an action to be taken on a packet. Special services can include 
proxy services, network address translation, and encryption, for example. In Fig. 3, the categories "Source Host," 
"Destination Host" and "Service" impose conditions which must be satisfied by data included in a packet for the specified 
action to be taken on that packet. Other conditions can be included, and such conditions need not relate to data included 
in the packet. For example, application of a rule can be made conditional on the time of day or day of the week. 
[0029] When a category provided for in the rule table is irrelevant in a certain rule, the corresponding table entry can 
be marked as a "wild card." This can apply to any one or any combination of the categories. In Fig. 3 and elsewhere, 
an asterisk (*) is used for wild card entries. "FTP" stands for "file transfer protocol." 

[0030] In rule processing for a packet, the rules are applied sequentially until a rule is found which is satisfied by the 
packet (or until the rule table is exhausted, in which case the packet is dropped). For a packet to satisfy a rule, each 
condition included in the rule must be met. For example, with reference to Fig. 3, a packet from source host A to 
destination host D and representing mail will be dropped under Rule 20. The following is a more detailed list of exemplary 
rule set categories in accordance with the invention. The first five category names correspond to the categories shown 
in Fig. 3. 



Category Name 



Description 



Rule Number 

Source Host 
Destination Host 
Service 
Action 

Notify on Drop 

Cache Timeout 
Reset Session 

Rule Timeout 
Start Period 
End Period 

Kill Session at End of Period 

Dependency Mask 
In Interface 
Out Interface 
Audit Session 

Alarm Code 

Source Host Map Group 
Source Host Map Type 
Destination Host Map Group 
Destination Host Map Type 
Service Map Group 

Service Map Type 
Max Use Total Count 

Max Use Concurrent Count 

Copy to Address 



Number of rule within domain. Rule numbers do not have to be unique but should 

generally represent a single service, such as FTP 

Source host group identifier or IP address 

Destination host group identifier or IP address 

Service group or protocol/destination port/source port 

Rule action, e.g., "pass, 1 "drop" or "proxy" 

If "yes," an Internet Control Message Protocol (ICMP) message is sent out if 
action is "drop" 

Number of seconds of inactivity before session entry is removed from cache 
If "yes," for TCP sessions, send TCP reset to both ends of connection upon cache 
timeout 

Number of seconds of inactivity before rule is removed from rule list 
Start active period for rule 
End active period for rule 

If "yes M then any sessions authorized by this rule will be killed at the end of the 
time period 

Dependency mask name 

Interface name to match on reception 

Interface name to which packet is sent 

Audit record generation. If "yes" then audit record is generated at the beginning 

and again at the end of the session. 

Alarm code value used to tie rule to particular alarms 

IP address or host group containing map-to host IP addresses 

Type of mapping to be performed, e.g., "pool" or "direct" 

IP address or host group containing map-to host IP addresses 

Type of mapping to be performed, e.g., "pool" or "direct" 

Service group containing map-to destination port numbers or the destination port. 
Protocol and source port in a referenced service group are ignored. 
Type of mapping to be performed, e.g., "pool" or "direct- 
Maximum number of times this rule may be used. The rule is removed after the 
limit is reached. 

Maximum number of sessions authorized by this rule which may be active at a 
given time. The rule is inactive until the count falls below the designated value. 
Address of application to which a copy of packet is sent. Used for session 
captures. 



5 



■)0CID: <EP 0909074A1_I_> 



EP 0 909 074 A1 



the cache, the rule set for the source domain is searched for a match; if a match is found in the rules and if the 
action is not "drop,* the process continues with step 505; if a match is found in the rules and the action is "drop," 
a corresponding entry is included in the cache, the packet is dropped, and the process returns to step 501; if no 
match is found in the rules, the packet is dropped and the process returns to step 501 : 
5 505: the destination interlace is determined using the local area network (LAN) address of the packet, and, if the 

source domain rule specifies a destination interface, using that destination interface and a routing table. 
506: using the destination interface and the destination address of the packet, the destination domain is determined; 
if the destination domain is not found, or if the destination domain matches the domain just checked, the process 
. skips to step 508: 

w 507: cache look-up and, if required, rule set look-up for the destination domain are carried out in a manner anal- 

ogous to that employed for the source domain in step 504; 

508: if a rule that applies to the packet calls for an address change, e.g., to a proxy or for insertion of one packet 
into another ("tunnel option"), the process returns to step 505 for processing based on the changed destination; 
509: if the packet was not processed with respect to any domain, the packet can be dropped, as a firewall owner 
is has no interest in supporting communications between interfaces which are not subject to any access rules; 

510: with all actions having resulted in "pass," the packet is sent out the appropriate network interface. 

[0035] For convenient linking of each network interface to a domain, a domain table is used. In cases where an 
interface is shared by multiple domains, an address range is included. This is illustrated by Fig. 6 which shows non- 
20 overlapping address ranges. 

[0036] Fig. 7 illustrates domain table processing as performed in steps 503 and 506 described above, including the 
following steps: 

701: the domain table is searched for a match of the interface name; 
25 702: if a matching tabic entry is found, and if the IP address range is present in the matching tabic entry, the packet 

address is checked as to whether it is within the range; if so, the specified domain is selected; otherwise, the search 
continues with the next table entry; 

703: if the end of the table is reached without a match having been found, no action is taken. 
30 3 Dependency Mask 

[0037] For protocols of the type which require a separate, additional network session from the outside back to the, 
user, such as, for example, the protocol employed by RealAudio, a rule can include a condition or mask that allows a 
connection back to a user, but only if there is a proper forward connection concurrently active, i.e., a connection in 
35 which the source and destination addresses are interchanged. As a result, there is no need for a separate or proxy 
application on the firewall. 

[0038] A dependency mask in accordance with the invention can define a query directed to the session cache. A. 
match is determined by matching all fields defined in the mask with the corresponding fields in the cache. Empty fields 
within the mask are not used for comparison. 
40 [0039] A dependency mask may be defined in a rule for the first packet of a network session, using (a) information 
in the packet, (b) the source interface for that packet and (c) one or several dependency conditions that must be met 
for the packet to pass. When such a first packet has been processed by the firewall, a corresponding entry is made in 
the cache. 

[0040] Fig. 8 shows rules with a dependency mask {"hit count") in a format similar to that of Fig. 3. Special symbols 
45 r are included for certain host designations, namely (i) a "dot" symbol (.) calling for inclusion of packet data of the cor- 
responding category, and (ii) a caret symbol ( A ) calling for inclusion of packet data from a certain different category 
instead. "Hit count" indicates the number of matches which must be found in the cache for the specified action to be 
taken. For example, in the dependency mask named "realaudio," a count of 1 is used for passing UDP packets provided 
one requisite TCP session is active. In the dependency mask "telnet," a count of 10 is used to drop packets to prevent 
so overloading of resources. 

[0041] Fig. 9 illustrates dependency mask processing including the following steps: 

901: the packet is obtained and the session key is extracted; 

902: the process steps through the rule set entries; if no match is found with a given rule, the process advances 
ss to the next rule in the set; if no match is found by the time the rule set is exhausted, the packet is dropped; if a 

match is found and the dependency mask field is null, the process skips to step 905; 

903: the packet and interface information may be included in the formation of a cache search structure, e.g.. a 
query; if a user authentication flag is set in the dependency mask, the corresponding flag is set in the cache search 
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1002: action associated with the packet is determined by looking in the appropriate session cache or, if not found 
in the cache, in ihe appropriate rule set: if ths action is "pass" or "proxy" packet processing continues: if the action 
is "drop." the packet is dropped: 

1003: if the action indicates a proxy application supported locally on the firewall, the packet is sent up the protocol 
5 stack to an awaiting proxy application: 

1004: if the action indicates a remote proxy, the packet's destination address is replaced with the address of the 
remote proxy: if configured, Ihe destination port can be changed as well: the original packet header data is recorded 
in the session cache along with any changed values; 
, 1005: the packet is routed to the remote proxy server. 

70 

[0050] Fig. 10B illustrates processing at the remote proxy, subsequent to step 1005, including the following steps: 

1005: the packet is received in the remote proxy server application; 
1007: the remote proxy contacts the firewall for the original session key for the packet; 

1003: the remote proxy application uses the original session key to perform its function, such as dropping the 
connection based on its own security model, performing the requested service, or contacting the original destination 
address on behalf of the user; if the remote proxy is using single reflection, the process skips to step 1011 ; 
1009: the remote proxy application contacts the firewall over the encrypted channel to request dual reflection 
capability; 

1010: the firewall determines a new destination port number that will guarantee uniqueness of the connection from 
the server; the firewall passes this new port number and the original session key back to the proxy application; 
101 1: the remote proxy application requests permission from the firewall for a connection from itself to the original 
destination; 

1012: the firewall loads a dynamic rule to perform this action; 

101 3: the remote proxy sends the packet to the firewall; based on the dynamic rule loaded in step 101 2, the firewall 
forwards the packet to the original destination; in the case of dual reflection, the proxy uses the destination port 
which was determined by the firewall in step 1010, and, as the packet passes through the firewall, the IP header 
values are changed back to the original values. 

30 [0051] Atl future packets associated with the same session are processed alike, except that steps 1007 and 
1009-1012 can be skipped. This is because the same dynamic rules apply for the life of the session. ; 
[0052] The invention can be implemented in a wide variety of applications. For example, the invention may be used 
to provide improved firewall performance in a dial-up access gateway. Another exemplary embodiment of the invention 
may be implemented in a distributed manner with a first portion of the firewall resident in the network and a second 

35 portion of the firewall resident in a set-top box : computer or other user terminal in a home or business. The latter 
embodiment can allow the firewall techniques of the invention to provide, for example, parental control of Internet and 
video access in the home. These and the other above-described embodiments of the invention are intended to be 
illustrative only. Numerous alternative embodiments within the scope of the following claims will be apparent to those 
skilled in the art. 

40 
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Claims 



1. A method for validating a packet in a computer network, comprising the steps of: 

45 

deriving a session key for said packet; 

selecting at least one of a plurality of security policies as a function of the session key; and 
using the selected at least one of the security policies in validating said packet. 

so 2. The method of claim 1 wherein the session key includes items derived from header information appended to data 
in said packet. 

3. The method of claim 1 wherein the session key includes at least one item from the set consisting of (i) a source 
address, (ii) a destination address, (iii) a next-level protocol, (tv) a source port associated with a protocol, and (v) 

55 a destination port associated with the protocol. 

4. The method of claim 1 wherein the session key includes at least one item from the set consisting of (i) an Internet 
protocol (IP) source address, (ii) an IP destination address, (iii) a next-level protocol, (iv) the source port associated 
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